9장. 변동성

출처: 『소프트웨어 설계의 결합 균형』(블라드 코노노프 지음, 장연호 옮김, 제이펍 2026) | 공식: https://www.jpub.kr/

자주 변하는 것과 안 변하는 것을 함께 묶으면 변경 비용이 폭증한다 — 결합의 시간 차원(모듈이 얼마나 자주 변하는가)이 결합 비용의 핵심 축이다.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• 결합이 시간 차원과 어떻게 연결되는지 설명한다 (변동성 개념).
• 소프트웨어가 변경되는 두 공간(솔루션·문제)과 주요 변경 원인을 열거한다.
• DDD 3종 하위 도메인(핵심·일반·지원)을 분류하고 각각의 변동성 수준을 예측한다.
• 소스 제어 분석(커밋 빈도)의 위양성·위음성을 판단한다.
• 인접 구성요소의 변동성이 전파된다는 개념(추론된 변동성)을 적용한다.

전체 흐름도

[ 결합 비용의 세 차원 ]
   공유 지식 (5장) + 수명주기 거리 (8장) + 변동성 (9장 ← 여기)
                                         │
                                         ▼
              [ 소프트웨어가 변하는 이유 ]
                 ┌────────────────┐   ┌────────────────┐
                 │  솔루션 공간   │   │   문제 공간    │
                 │  - 버그 수정  │   │  - 신규 요구사항│
                 │  - 기술 부채  │   │  - 비즈니스 변화│
                 │  - 조직 변화  │   │                 │
                 └────────────────┘   └────────────────┘
                                         │
                                         ▼
              [ DDD 하위 도메인 분류 → 변동성 예측 ]
          ┌──────────────┬──────────────┬──────────────┐
          │  핵심(Core)  │ 일반(Generic)│ 지원(Support)│
          │  변동성 HIGH │  변동성 LOW  │  변동성 LOW  │
          │  차별화 원천 │  검증된 솔루션│  단순 보조   │
          └──────────────┴──────────────┴──────────────┘
                                         │
                                         ▼
          [ 추론된 변동성 — 인접 구성요소로 전파 ]
          낮은 변동성 모듈 + 높은 변동성 모듈을 침입 결합으로 연결
                    → 실제 변동성 = 높음 (전파됨)
                                         │
                                         ▼
          [ 결론 ] 가장 변동성 큰 모듈(핵심) 경계에서 공유 지식을 최소화

0. 사전 필수 용어

• 변동성 (Volatility) — 구성요소가 얼마나 자주 변경될 것으로 예상되는가. 결합 비용의 시간 차원.
• 솔루션 공간 (Solution Space) — 설계·아키텍처·구현 방법. 버그 수정·리팩토링·기술 부채 해소.
• 문제 공간 (Problem Space) — 비즈니스 문제 정의. 신규 요구사항·기능 변경.
• 비즈니스 도메인 — 회사의 전반적인 활동 영역 (FedEx=택배, Walmart=소매).
• 하위 도메인 (Subdomain) — 비즈니스 도메인 내에서 운영하는 세분화된 비즈니스 활동 영역.
• 핵심 하위 도메인 (Core Subdomain) — 경쟁 우위를 제공. 변동성 높음. 자체 구현 필수.
• 일반 하위 도메인 (Generic Subdomain) — 검증된 기성 솔루션 활용 가능. 변동성 낮음.
• 지원 하위 도메인 (Supporting Subdomain) — 핵심·일반을 보조. 비즈니스 로직 단순. 변동성 낮음.
• 추론된 변동성 (Inferred Volatility) — 자체 변동성이 낮아도 변동성 높은 구성요소에 강하게 결합되면 실제 변동성이 높아지는 현상.
• 커밋 빈도 (Commit Frequency) — 소스 제어 분석으로 변동성을 추정하는 방법. 위양성·위음성 주의.
• 콘웨이의 법칙(Conway's Law) — 시스템 설계는 조직의 커뮤니케이션 구조를 모방한다. 조직 변화 → 설계 변화.

1. 변화와 결합 — 왜 시간 차원이 중요한가

핵심 통찰: 변화가 없으면 나쁜 결합도 문제없다

침입 결합이 가득한 시스템이라도 단 하나의 구성요소도 앞으로 변경될 예정이 없다면, 기술적으로는 "잘못된 설계"지만 실무 비용 관점에서는 문제가 없다. 연쇄 변경이 발생하려면 변경 자체가 있어야 한다.

핵심 통찰 — "결합 강도"만이 아니라 "변동성(얼마나 자주 변하는가)"이 함께 결합 비용을 결정한다. 결합 비용 = 결합 강도 × 변동성. 변동성이 0이면 결합이 아무리 강해도 비용은 0이다.

일상 비유: 옷장 정리와 변동성

옷장을 정리한다고 생각해 보자.

• 매주 입는 일상복(청바지, 티셔츠) = 변동성 높음
• 1년에 몇 번 꺼내는 명절옷·예복 = 변동성 낮음

이 두 종류를 같은 선반에 뒤섞어 두면 어떻게 될까? 매주 청바지를 꺼낼 때마다 명절옷을 헤집어야 한다. 반대로 선반을 분리하면, 일상복 선반은 매일 열어도 명절옷 선반은 건드리지 않는다. 자주 변하는 것과 안 변하는 것을 분리한 것만으로 관리 비용이 사라진다.

소프트웨어도 같다. 변동성이 다른 모듈을 강하게 결합하면, 자주 변하는 쪽이 바뀔 때마다 안 변해도 되는 쪽까지 끌려온다.

추가 비유: 팀의 코드 계층

• 신참 개발자의 실험적 코드 — 매일 수정됨 (변동성 높음)
• 10년 된 인증 라이브러리 — 거의 안 바뀜 (변동성 낮음)

신참 코드가 인증 라이브러리를 침입 결합으로 의존하면, 신참이 뭔가 바꿀 때마다 인증 라이브러리가 흔들린다. 반대로 계약 결합으로만 연결해 놓으면 신참 코드가 매일 바뀌어도 인증 라이브러리는 평화롭다.

2. 왜 소프트웨어는 바뀌는가?

소프트웨어 변경의 두 공간:

2.1 솔루션 공간의 변경

콘웨이의 법칙과 변동성

콘웨이의 법칙: "시스템을 설계하는 조직은, 그 조직의 의사소통 구조를 모방한 설계를 만들어낸다."

소규모 스타트업은 커뮤니케이션이 즉흥적이다 — "정수기 대화"로 API 변경을 조율할 수 있다. 대기업이 되면 그게 불가능해진다. 공식 통합 프로토콜이 필요하고, 팀 간 변경 조율 비용이 폭증한다.

비유: 식구 수에 따른 가족 규칙

3인 가족은 저녁 메뉴를 카톡 한 줄로 결정한다. 30인 대가족 명절 모임은 공식 음식 담당표, 준비물 체크리스트, 도착 시간표가 필요하다. 가족 수(=조직 규모)가 바뀌면 소통 방식(=시스템 설계)이 따라 바뀐다.

2.2 문제 공간의 변경

비즈니스 요구사항이 변한다. 새 기능, 기존 동작 수정, 새로운 시장 기회. 구성요소마다 변경 빈도가 다르다 — 어떤 기능은 매주 요구사항이 바뀌고, 어떤 기능은 수년째 그대로다.

왜 불균등한가? 비즈니스 이해관계자가 경쟁력을 좌우하는 핵심 기능에 집중하기 때문이다. 그게 바로 핵심 하위 도메인이다.

3. 변경률 평가하기 — DDD 하위 도메인 분류

3.1 도메인 주도 설계(DDD) 분류

비즈니스 도메인 vs 하위 도메인

• 비즈니스 도메인 — 회사 전체 활동 영역. (FedEx = 택배 배달)
• 하위 도메인 — 비즈니스 도메인 안의 세분화된 활동 블록. 회사를 경쟁사와 차별화하는 것이 하위 도메인이다.

기술적 관점에서 하위 도메인은 밀접하게 관련된 데이터로 작동하고 관련 기능을 설명하는 일련의 상호 관련된 사용 사례로 정의된다.

핵심 하위 도메인 (Core) — 변동성 높음

경쟁 우위를 제공하는 기능. 회사의 비밀 소스 (Secret Sauce).

특징: - 복잡성 높음 (최적 솔루션을 시행착오로 발견) - 경쟁자가 복제하기 어렵도록 계속 진화시켜야 함 - 기성품 솔루션이 없음 — 직접 구현 필수 - 커네빈 "복잡한 도메인" — 실험 → 관찰 → 적용의 반복

변동성이 높은 이유: 최적 솔루션이 계속 바뀌고, 경쟁사를 앞서기 위해 지속 진화해야 한다.

WolfDesk 사례 (고객 서비스 소프트웨어): - 지원 사례 관리 (자동 응답·상태 전환 지속 개선) - 배포 알고리즘 (사례-에이전트 최적 매칭) - 지식 기반 (독점 문서 자동 검색)

일상 비유: 레스토랑의 시그니처 메뉴 레시피. 경쟁 카페보다 더 맛있는 커피를 내기 위해 원두 배합·추출 시간·온도를 끊임없이 실험하고 수정한다. 이 레시피는 절대 완성된 채로 머물지 않는다.

일반 하위 도메인 (Generic) — 변동성 낮음

기성 검증 솔루션을 활용. 경쟁사도 같은 솔루션 사용 가능.

특징: - 직접 만들 필요 없음 (오픈소스·상용 제품) - 이미 실전 테스트 완료 → 대규모 변경 없음 - 커네빈 "복합 도메인" — 전문가가 올바른 답을 안다

WolfDesk 사례: 신원·액세스 제어, 청구 (Auth0·Stripe 같은 서비스 활용)

일상 비유: 레스토랑의 세금 계산·회계. 모든 레스토랑이 똑같은 세법·회계 소프트웨어를 쓴다. 내가 특별한 회계 방식을 개발해봐야 경쟁 우위가 없다. 그냥 QuickBooks 쓰면 된다.

지원 하위 도메인 (Supporting) — 변동성 낮음

핵심·일반을 보조. 직접 구현해야 하지만 경쟁 우위 없음.

특징: - 비즈니스 로직 단순 - 기성 솔루션이 없어서 직접 만들지만, 수익에 직접 영향 없음 - 커네빈 "명확한 도메인" — 원인·결과가 뚜렷

WolfDesk 사례: 데스크 관리 (헬프 데스크·에이전트 정보 입력화면 — 대부분 CRUD)

일상 비유: 레스토랑의 직원 출퇴근 기록. 독창적인 방식이 필요하진 않지만, 표준 앱이 딱 맞지 않아 간단한 시트로 직접 만든다. 절대 자주 바뀌지 않는다.

잘못된 예 vs 올바른 예 — 변동성 혼합

잘못된 예: 자주 변하는 핵심과 안 변하는 지원을 침입 결합으로 연결

# 핵심 하위 도메인: 알고리즘이 자주 바뀜
class CaseMatcher:
    def match(self, case):
        # ... 복잡한 매칭 알고리즘 (매월 수정)
        return self._agent_pool  # 내부 구조 직접 노출

# 지원 하위 도메인: 단순 보조 기능
class DeskManager:
    def __init__(self, matcher: CaseMatcher):
        self.matcher = matcher

    def assign(self, case):
        # 침입 결합: CaseMatcher의 내부 _agent_pool에 직접 접근
        pool = self.matcher._agent_pool  # ← 내부 구현 침범
        agent = pool.agents[0]
        agent.assign(case)

문제: CaseMatcher(핵심, 매월 수정)의 내부 구조가 바뀔 때마다 DeskManager(지원, 안 바꿔도 되는데)가 깨진다.

올바른 예: 계약 결합으로 변동성 전파 차단

# 핵심 하위 도메인: 내부는 자유롭게 진화
class CaseMatcher:
    def get_best_agent(self, case) -> Agent:  # 공개 계약만 안정
        return self._run_algorithm(case)

# 지원 하위 도메인: 계약만 의존
class DeskManager:
    def __init__(self, matcher: ICaseMatcher):
        self.matcher = matcher

    def assign(self, case):
        agent = self.matcher.get_best_agent(case)  # 계약만 사용
        agent.assign(case)

결과: CaseMatcher 내부 알고리즘이 매월 바뀌어도 DeskManager는 전혀 영향받지 않는다.

3.2 소스 제어 분석 (커밋 빈도)

브라운필드 프로젝트에서 이미 존재하는 코드의 변동성을 추정하는 실용적 방법: 커밋 횟수 측정.

# 모듈별 커밋 횟수로 변동성 추정
git log --oneline -- src/case_matcher/ | wc -l   # 핵심 하위 도메인
git log --oneline -- src/desk_manager/ | wc -l   # 지원 하위 도메인

주의: 위양성 (False Positive)

모든 커밋이 같은 의미가 아니다.

• 버그 수정 커밋 → 핵심 하위 도메인 신호 아님
• 기능 추가·기존 기능 수정 → 핵심 하위 도메인의 강한 신호

주의: 위음성 (False Negative)

커밋이 적어도 실제 변동성이 높을 수 있다.

"한번은 변경 빈도가 낮은 모듈을 발견했지만, 설명에 핵심 하위 도메인이라고 나와 있었기 때문에 무언가 맞지 않았다. 코드가 너무 엉망이어서 수정하려고 하면 중단이 광범위하게 일어났다. 결과적으로 회사는 기능을 발전시키려는 노력을 포기하고 다른 영역에 집중했다." — 저자

비유: 오래된 오두막집이 리모델링 기록(=커밋)이 거의 없다고 해서 상태가 좋은 건 아니다. 너무 낡아서 손댈 엄두를 못 내는 것일 수 있다.

4. 변동성과 결합 강도 — 세트로 봐야 한다

같은 구성요소, 다른 비용

두 시스템이 완전히 같은 구성요소 수와 같은 통합 강도를 가진다고 해도, 어떤 구성요소가 핵심 하위 도메인을 구현하느냐에 따라 비용이 완전히 달라진다.

시스템 A (좋은 설계):
  [핵심] ←계약 결합← [지원]
   자주 바뀜       계약이 안정됐으므로 영향 없음

시스템 B (나쁜 설계):
  [핵심] ←침입 결합← [지원]
   자주 바뀜       매번 깨짐

핵심 포인트: 핵심 하위 도메인(가장 자주 변함) 경계에서 공유 지식을 최소화하는 것이 가장 중요하다.

일상 비유: 건물 내진 설계

지진이 자주 나는 지역(=변동성 높음)에 있는 건물 연결부는 유연하게(=약한 결합) 만들어야 한다. 지진이 없는 지역 건물은 연결부가 빡빡해도(=강한 결합) 문제없다. 같은 빡빡한 결합이라도 얼마나 자주 흔들리느냐에 따라 비용이 전혀 다르다.

하위 도메인 유형별 결합 전략

5. 추론된 변동성 — 인접 구성요소의 변동성 전파

핵심 개념

구성요소 자체의 변동성이 낮아도, 변동성 높은 구성요소에 강하게 결합되면 실제 변동성은 높아진다.

[지원 하위 도메인 구성요소]  ←침입 결합← [핵심 구성요소 A, 변동성 HIGH]
         자체 변동성: 낮음                  ←침입 결합← [핵심 구성요소 B, 변동성 HIGH]
         실제 변동성: 높음 !!!             ←침입 결합← [핵심 구성요소 C, 변동성 HIGH]

지식은 종속성 방향과 반대로 흐른다 — 지원 구성요소가 핵심 세 개에 침입 결합으로 종속되면, 핵심 셋이 바뀔 때마다 지원이 끌려온다.

일상 비유: 미용사와 유행

동네 미용사(=지원 하위 도메인)는 자기 일 자체는 잘 안 바뀐다. 그런데 최신 유행 스타일 세 가지 트렌드에 침입 결합으로 의존하면 — 매 시즌 유행이 바뀔 때마다 기법을 싹 다 바꿔야 한다. 반면 "고객이 원하는 스타일을 구현한다"는 계약만 의존하면 — 유행이 뭐로 바뀌든 기본 기술만 쓰면 된다.

추론된 변동성 계산 원리

실제 변동성 = max(자체 변동성, 의존하는 구성요소들의 변동성 × 결합 강도)

강한 결합 + 높은 변동성 이웃 = 폭발

잘못된 예 vs 올바른 예 — 추론된 변동성

잘못된 예: 지원 모듈이 핵심 세 개를 침입 결합으로 의존

# 지원 하위 도메인: 단순 대시보드 (자체 변동성 낮음)
class SupportDashboard:
    def show(self):
        # 세 핵심 모듈의 내부 상태에 직접 접근 (침입 결합)
        matches = CaseMatcher._algorithm_state  # ← 핵심1 내부
        kb = KnowledgeBase._internal_index      # ← 핵심2 내부
        dist = Distributor._queue_impl          # ← 핵심3 내부
        # ... 화면에 표시

세 핵심 모듈이 매달 바뀌면 SupportDashboard도 매달 깨진다.

올바른 예: 계약 결합으로 변동성 절연

# 각 핵심 모듈이 안정적인 계약을 제공
class ICaseMatcher:
    def get_status(self) -> MatcherStatus: ...

class IKnowledgeBase:
    def get_summary(self) -> KbSummary: ...

class IDistributor:
    def get_queue_stats(self) -> QueueStats: ...

# 지원 모듈은 계약만 의존
class SupportDashboard:
    def __init__(self, m: ICaseMatcher, kb: IKnowledgeBase, d: IDistributor):
        ...
    def show(self):
        status = self.matcher.get_status()  # 계약만
        summary = self.kb.get_summary()     # 계약만
        stats = self.d.get_queue_stats()    # 계약만

세 핵심 모듈 내부가 매달 바뀌어도 SupportDashboard는 계약이 유지되는 한 안전하다.

핵심 개념 정리

실무 체크리스트

• [ ] 새 모듈을 설계할 때 "이 모듈은 핵심/일반/지원 중 어느 하위 도메인인가" 먼저 분류했나?
• [ ] 핵심 하위 도메인 경계에서 공유 지식을 최소화(계약 결합 이하)했나?
• [ ] 소스 제어 커밋 분석 시 버그 수정 커밋과 기능 변경 커밋을 구분했나?
• [ ] 커밋 수가 적은 모듈을 "안정적"으로 단정하기 전에 코드 품질도 확인했나?
• [ ] 지원 하위 도메인 모듈이 핵심 하위 도메인 모듈과 강하게 결합돼 추론된 변동성이 올라가진 않았나?
• [ ] 하위 도메인 유형에 따른 결합 전략을 다르게 적용했나? (핵심 = 계약 최소화, 지원 = 더 허용)
• [ ] 조직 구조 변화 시 어떤 모듈의 변동성이 올라갈지 미리 분석했나?

연습문제 (문제만 — 정답은 부록 D)

1. 개념. "변동성이 0이면 결합 강도가 아무리 높아도 비용이 없다"는 주장이 실무에서 완전히 참인가? 반례를 하나 제시하라.

2. 분류. 다음 기능 중 핵심/일반/지원 하위 도메인을 분류하고 이유를 설명하라.

3. (a) 전자상거래 플랫폼의 "상품 추천 알고리즘" (Netflix식 협업 필터링 자체 구현)
4. (b) 전자상거래 플랫폼의 "PG사 결제 연동" (KG이니시스 SDK 사용)

5. (c) 전자상거래 플랫폼의 "판매자 입점 신청 폼" (단순 CRUD)

6. 소스 제어 분석. 한 모듈의 git 커밋 수가 최근 6개월간 2건이다. 이 모듈의 변동성이 낮다고 결론 내릴 수 있는가? 판단에 필요한 추가 정보 두 가지를 제시하라.

7. 추론된 변동성. 지원 하위 도메인을 구현하는 ReportService가 세 개의 핵심 하위 도메인 구성요소에 침입 결합으로 의존한다. ReportService의 실제 변동성은 어떻게 되는가? 이를 해결하기 위한 설계 변경을 제안하라.

8. 적용. 당신이 속한 팀의 코드베이스 중 하나를 골라 핵심/일반/지원 하위 도메인으로 구성요소를 분류해 보라. 가장 변동성이 높을 것으로 예상되는 구성요소와, 그 구성요소가 현재 어떤 결합 강도로 이웃 모듈과 연결돼 있는지 확인하라.

최신 동향 (2026-05 기준)

최신 동향 (검증 2026-05-21)

• DDD 하위 도메인 분류 자동화 — Wardley Mapping 기반 도구들이 비즈니스 도메인 구성요소를 핵심/일반 분류 지원. Context Mapper는 바운디드 컨텍스트와 하위 도메인 유형을 DSL로 명시할 수 있어 변동성 설계 문서화에 활용 증가.
• 변동성 시각화 — Git 커밋 분석 도구 고도화 — CodeScene의 "Hotspot 분석"은 커밋 빈도 × 코드 복잡도를 교차해 위양성/위음성을 줄인 변동성 추정 제공. 단순 커밋 수보다 정확하다.

부록 A. 용어 사전

부록 B. 핵심 비교표

DDD 세 가지 하위 도메인 비교

결합 강도별 변동성 전파 비교

부록 C. 추천 참고 자료 & 링크

Tier 1 공식·표준 (생존 확인 2026-05-21)

책 다른 장 안내

부록 D. 연습문제 풀이

1. (완전한 참은 아니다) 구성요소가 지금은 안 변하지만 미래에 변경될 가능성이 있다면, 강한 결합은 나중에 비용이 된다. 또한 변동성이 낮은 모듈도 새 팀원이 읽어야 한다 — 콘텐츠 결합(5장)처럼 이해하기 어려운 코드는 변경 없이도 인지 비용을 유발한다. "지금 비용 없음"과 "앞으로도 비용 없음"은 다르다. 현실 반례: 스타트업 초기 "이 기능은 절대 안 바뀐다"고 가정했던 모듈이 피벗 후 핵심 하위 도메인이 되는 경우.

2. (분류)

3. (a) 핵심 — 자체 개발한 추천 알고리즘은 경쟁 우위 원천. 지속 실험·개선 필요. 변동성 높음.
4. (b) 일반 — PG사 SDK는 기성 검증 솔루션. 경쟁 우위 없음. 변동성 낮음(보안 패치 정도).

5. (c) 지원 — 입점 신청 CRUD는 단순 로직. 경쟁 우위 없음. 기성품 없어서 자체 구현하지만 변동성 낮음.

6. (추가 정보 두 가지 필요) ① 커밋 내용 유형 — 2건이 모두 기능 추가라면 강한 변동성 신호. 버그 수정이라면 약한 신호. ② 코드 품질·복잡도 — 커밋 수가 적은 이유가 안정적이어서인지 너무 복잡해서 손 못 대는 것(위음성)인지 확인. 코드 순환 복잡도·결합도를 함께 분석해야 한다.

7. (추론된 변동성으로 실제 변동성 높음) ReportService는 지원 하위 도메인(자체 변동성 낮음)이지만 세 핵심 구성요소에 침입 결합으로 의존하므로 핵심 세 개 중 하나라도 바뀌면 ReportService도 깨진다. 실제 변동성 = 높음. 해결: 각 핵심 구성요소가 안정적인 계약 인터페이스(get_status(), get_summary() 등)를 제공하도록 리팩토링. ReportService는 그 계약에만 의존.

8. (개방형) 예시 답: e-커머스 플랫폼의 경우 — "개인화 추천 엔진"(핵심, 변동성 높음)이 현재 "주문 이력 서비스"(지원, 변동성 낮음)와 함께 같은 DB를 직접 읽는 공통 결합 상태라면, 주문 이력 스키마가 바뀔 때마다 추천 엔진도 수정해야 한다. 개선: 주문 이력 서비스가 공식 API(getRecentOrders(userId))를 제공하고 추천 엔진은 API만 호출.